最近要做个预警列表的已读未读功能，这个是推送过来的，我想了想，已读未读是针对用户来的，每个用户对应着一套列表的已读未读，假如我们每条数据都给每个用户对应读取状态，那是多对多的关系，得多少数据啊，想想都可怕。

方案一：刚开始也懒，想让android和ios自己存取数据的读取状态，他们相对于我很少的数据量就能解决，但是他们存本地是有一个缺点的，假如清理缓存和卸载，这个已读未读就将全部清空，显然不合理，只有存服务器端才是正确的选择，

方案二：我想了想，假如我将一个用户的未读id拼成一个字符串放在一张表中，用户点击一条数据，删除一个未读的id，当删除完的时候删除整条数据，这样感觉还不错，但是有一个问题，就是假如消息一直堆加，而用户一直未读，就会一直追加到爆炸，也不是很合理，我又想了想，假如我设定最大的未读数量为50，超过50条会删除前边的一条，追加上最新的一条，这样也挺不错的，这是一种可行的办法。

方案三：我感觉这种方式跟用户的订单类似，也是不断递增的，订单跟用户也是相关联的，也是多对多的关系，订单都能存数据库中，我的列表的多对多也能存在数据库中，那就存吧，因为我的是推送过来的，只有开着消息开关的才会给用户推送消息，所以消息也并不都是所有的，那就存数据库吧，点击修改消息状态就好了，这样逻辑最简单。